Lost and Found Tagging and Communication System and Method

ABSTRACT

A method and system of facilitating communication between a finder of an article and an owner of the article including providing a unique ID to the owner and allowing the owner to register an association between the ID and owner contact information, allowing the owner to associate the ID and a virtual locale with the article, and forwarding communications of the finder of the article to the owner where the finder may provide no more information to the virtual locale than the ID and the communication.

CROSS REFERENCE TO RELATED APPLICATION

The present application is a continuation of U.S. patent applicationSer. No. 13/180,366, filed Jul. 11, 2011, which is a continuation ofU.S. patent application Ser. No. 11/602,491 filed Nov. 21, 2006, nowU.S. Pat. No. 7,978,068, issued Jul. 12, 2011 which in turn claimspriority under 35 U.S.C. §119(e) to U.S. provisional patent applicationNo. 60/597,297 filed Nov. 21, 2005. Each application is incorporatedherein by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates to methods and systems for allowing aperson, such as a finder of a valuable or other object, to communicatewith the owner of the valuable or other object.

BACKGROUND OF INVENTION

All U.S. Patents referred to herein are hereby incorporated by referencein their entireties. In the case of conflict, the present specification,including definitions, will control.

For as long as there have been portable possessions, there have beenopportunities to for them to be mislaid or go missing. When suchpossessions have intrinsic, subjective and/or sentimental value, theloss can be especially difficult for the owner of the possession. Intoday's society such possessions and objects might include a ring ofkeys, a portable music player with a large music collection, a laptopcomputer, a digital camera containing the only copy of treasured familyphotos, or any number of portable objects.

One time-tested method of protecting against the permanent loss of anobject is for the owner to write her name and contact information, forexample, a phone number and an address, on the object or on a tag orlabel attached to the object. Then, when the object is lost or otherwiseseparated from its owner, a person finding the object can use the nameand contact information to contact the owner and communicatearrangements for the return of the object to the object's owner.However, this approach has drawbacks. First, such an approach providesinformation about the owner's identity to an unknown person. If the lostobject were a ring of keys, a finder with mal-intent could use theinformation on the tag to discern the identity and address of the ownerand then use the keys to gain access to her residence. Second, such anapproach may not provide contact information with the best currency—suchas when the owner is traveling or has recently moved. If the informationon the tag is not current and the finder cannot quickly communicate withthe owner, an opportunity may be lost for the finder to return theobject to the owner before the owner continues in her travels.

Another method for tagging possessions to protect against their loss isreferred to in U.S. Pat. No. 6,259,367 to Klein. This patent refers tothe use of RFID tags encoded with “obfuscated” owner information. TheRFID encoded information may be used to retrieve a file containing moredetailed owner contact information. A drawback to Klein's approach isthat a finder must gain access to an RFID tag reader and appropriatesoftware to decode the information and access the file through anetwork. When this is done through a third party, either the third partymust disclose the owner's private contact information or the finder musttrust the third party to return the item to the owner. As withconventional tags, Klein's system may lack the most current contactinformation, create delays (and lost opportunities) in returningpossessions, and result in the loss of owner privacy.

Other systems purport to overcome these disadvantages but fall short.Some require the use of a shipping intermediary in order to return theobject to its owner. Some require a third party intermediary to processa “found” report and provide return instructions to a finder.

SUMMARY OF THE INVENTION

The present invention overcomes the disadvantages of the prior systemsby providing for a timely and anonymous communication channel between afinder of an object and an owner of an object.

In accordance with one aspect of the invention, there is a method offacilitating communication between a finder of an article and an ownerof the article which includes providing a unique ID to the owner,allowing the owner to register an association between the ID and ownercontact information, allowing the owner to associate the ID and avirtual locale (for example, a website address) with the article, andforwarding communications of the finder of the article to the ownerwhere the finder may have provided no more than the ID and thecommunication to the virtual locale.

In accordance with another aspect of the invention, there is a systemfor facilitating communication between a finder of an article and anowner of the article which includes a virtual locale, a database forstoring an association between owner contact information and a uniqueID, and a module for forwarding finder communications to the owner wherethe finder provides as little information as the communication and theunique ID to the virtual locale.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A, 1B, 1E, 1F, 1G, 1H, 1I, 1J, 1K, 1L, 1M, 1N, 1O, 1P, 1Q, 1R,1S, 1U, 1V, 1X, 1Y, and 1Z depict steps of a method in accordance with apreferred non-limiting embodiment of the invention;

FIGS. 2A and 2B depict examples of tags with associated IDs andreference addresses that could be employed in accordance withembodiments of the invention;

FIG. 3 depicts a main menu that could be employed in accordance withembodiments of the invention;

FIG. 4 depicts an owner main menu that could be employed in accordancewith embodiments of the invention;

FIG. 5 depicts an ID registration screen that could be employed inaccordance with embodiments of the invention.

FIG. 6 depicts an open case screen that could be employed in accordancewith embodiments of the invention;

FIG. 7 depicts a new user screen that could be employed in accordancewith embodiments of the invention;

FIG. 8 depicts a contact information screen that could be employed inaccordance with embodiments of the invention;

FIG. 9 depicts a view/edit tag screen that could be employed inaccordance with embodiments of the invention;

FIG. 10 depicts a finder main menu that could be employed in accordancewith embodiments of the invention;

FIG. 11 depicts a send message menu that could be employed in accordancewith embodiments of the invention;

FIG. 12 depicts a short one way message entry screen that could beemployed in accordance with embodiments of the invention;

FIGS. 13A and 13B depict anonymously addressed e-mails that could beemployed in accordance with embodiments of the invention; and

FIG. 14 depicts an instant message that could be sent in accordance withan embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description, reference is made to variousspecific embodiments in which the invention may be practiced. Theseembodiments are described with sufficient detail to enable those skilledin the art to practice the invention, and it is to be understood thatother embodiments may be employed, and that structural and logicalchanges may be made without departing from the spirit or scope of thepresent invention.

The present invention provides systems and methods that allow a person,such as a finder of a lost or misplaced object, to anonymouslycommunicate with another, such as the owner of the object. The systemsand methods can be useful in facilitating the return of the object toits owner.

In an aspect of the invention, an “owner,” which can be an individual orentity wishing to protect portable personal property, is provided withspecially prepared tags. With reference to FIGS. 2A and 2B, such tagscan be of any size or shape or type, such as a printed adhesive label200, a sew-on patch (not pictured), a plastic key-ring tag 250 with ahole for a key ring or keychain 230, or even an electronic tag (e.g. anRFID) (not pictured). Two common features of the tags of the presentinvention are a unique identifying feature such as an ID (e.g., a stringof alphanumeric characters) 210 and a reference to a specific website orother unique virtual locale (e.g., a text messaging number, an SMSnumber, or an instant messaging screenname) 220. The ID 210 may beprinted and/or electronically stored on or within the tag. As with theID, the reference to the specific website or other virtual locale 220may also be printed and/or electronically stored.

As used in some of the figures, a tag is referred to as a zTag and an IDis referred to as a zID.

In an embodiment, the owner would then affix tags 200 or 250 to anyportable possession which she desires to be easily returned to her iflost or otherwise separated from her. Such objects and possessions mightinclude an attaché case, a ring of keys, a portable music player with alarge collection of music, a digital camera with irreplaceable familyphotos, a cell phone, and the like.

Having been provided with tags and having affixed the tags to variouspossessions, the owner can then register the tag IDs and the owner'scontact information on a centralized and network accessible databaseaccording to the present invention.

With reference to FIG. 1A, a user, in this case, an owner, accesses abrowser or client capable device, starting its operating system, ref. 1,if necessary. Then the user navigates to the server, ref. 2, using thebrowser or client capable device and receives a main menu, ref. 3.

With reference to FIGS. 3 and 1A, the server displays a menu 300, ref.4, which in a preferred embodiment has a menu button for requesting theowner menu 310, a menu button for requesting the finder menu 320, and adata field for entering an ID of a found object 330.

In an exemplary embodiment, a user who is new to the system can selectthe option 340 “sign-up and register,” ref. 13 (FIG. 1B), from the mainmenu. When this option is selected, a data entry screen is displayed.With reference to FIG. 7, the data entry screen may optionally bepreceded by a “bot-killer” registration screen 700, in which the userenters initial credentials such as an email address 710 and password720, and additionally enters a Verification Code in a field 730, wherethe Verification Code 740 is displayed in a optically obfuscated mannerso that an automated “bot” cannot register as a user. The registrationscreen may optionally include a consent to usage terms feature 750.Following this optional bot-killer data entry screen, with reference toFIG. 8, the screen 800 may include fields for adding and editing datasuch as the user's name 840 and various types of contact info, ref. 33.Generally, in addition to a password, the only other required field isan unambiguous contact field entry, such as the user's email address850. If a user selects “save changes” or “add the new user,” ref. 34,the entered data is validated, ref. 35, and the new user is added to thedatabase, ref. 37. Then the main owner screen is displayed, ref. 7 (FIG.1B). Should the entered email address already exist in the database, theuser is alerted to the error, ref. 36, and this procedure is restarted,ref. 33. In a preferred embodiment, there is an option that the user canalways select, ref. 38, to return to the main owner menu, ref. 7,without entering any information.

When a user selects the owner option 310, ref. 4, the main owner menu400 (FIG. 4) is displayed, ref. 7 (FIG. 1B). The owner menu offers ownerrelated choices, including going back to the Main Menu, ref. 8.

Should a user select Owner Log On, ref. 9, an Owner Log On screen isdisplayed (not shown) and the user is prompted for their email addressand password, ref. 62 (FIG. 1K). The system verifies these credentialsagainst those in a database to determine whether they match a validuser, ref. 63. If there is a match, a flag is set to indicate that theowner is logged on for this session, ref. 64, and the owner's uniqueuser id, herein userid, is placed in memory for future reference. Ifthere is no match, an appropriate error message is displayed to theuser, ref 65. Once these steps are completed, the main owner menu isdisplayed, ref. 7 (FIG. 1B).

An owner wishing to associate an ID with his or her contact informationmust register the ID with the database. In an exemplary embodiment, theowner/user selects the “add a zTag” menu item 410 (FIG. 4), ref. 10, andis prompted, ref. 15 (FIG. 1E), with a screen 500 as shown in FIG. 5containing fields for entry of the relevant information for that tagsuch as its ID 510 and a description 520 of the associated object orpossession. However, before entering this part of the program,subroutine D is called to validate that the “owner logged on” flag isset to true, ref. 39 (FIG. 1L), and return, ref. 40, to the calling stepin the application if so, or display an appropriate message, ref. 41,and return to the main owner menu, ref. 7 (FIG. 1B), if not. Once theuser supplies the information and selects “add item” 530, ref. 16 (FIG.1E), the server confirms that the data is in the valid format, ref. 17,and that the user has entered a valid and available ID, ref. 19. Anyerror in this process is displayed to the user, ref. 18 and the screen500 may be displayed, ref. 15. If there are no errors, the database isupdated with the tag information and the database record is associatedwith the user, ref. 20. Control then passes to the main owner menu 500,ref. 7. There, the user may opt, ref. 21, to return to the main ownermenu, ref. 7, without entering any information.

In the illustrated embodiment, when an owner wishes to see open cases,where an open case is defined as an instance of an open line ofcommunication with a finder of an owner's tagged item, they select themenu item “view open cases” 450, (FIG. 4), ref. 11 (FIG. 1B). Beforedisplaying the view open cases screen, subroutine D is executed in amanner similar to that earlier described with regard to subroutine D.The database is then queried for any open cases where the user's useridis listed as the owner. Retrieved records are used to create a list 600(FIG. 6), which is displayed to the user, where each line is related toan open case, and includes information from that particular case. Forexample, a list of open cases might include an ID of a tagged object 610and a description of the tagged object 625. Links may be associated witheach case-related line which enable a user to close the case 650 orcommunicate with the finder of that case 620. There are numerous optionsthroughout this menu, and its submenus, so that the user can alwaysselect an option, ref. 31 (FIG. 1F), to return to the main owner menuwithout entering any information. If a user selects “close case,” ref.25, the case is marked as closed in the database, ref. 26, and the opencase screen 600 is updated, ref. 22. Should the user select to contactthe finder of a particular case, ref. 27, they are prompted and given afield to type their email message, ref. 28. In one embodiment, afinder's anonymous email address is displayed with a reminder that theuser can email the finder using their own email program. Once the userselects “send message,” ref. 29, the finder's real email address is used(yet never displayed to the user) to send an email, ref. 30. This partof the program is then directed to restart, ref. 22.

Existing users can choose to edit their account settings, ref. 12.Before displaying the account settings editing screens, subroutine D isrun in a manner similar to that already described with regard tosubroutine D. The database is queried for information associated withthis user through use of a userid. In one embodiment, the userinformation will be displayed in editable fields, ref. 45. Withreference to FIG. 8, such fields may include fields for the user's name810, addresses, password 860, Instant Message Handles 810, 820, and 830,phone numbers, and so on. The user may select to return, ref. 50, to themain owner menu, ref. 7, without entering any information. If the userselects “save changes,” ref. 40, the system confirms that the new dataare valid, ref. 47, and if so, saves the record to the database, ref.48. Then the main owner window, ref. 7, is then displayed to the user.If the validation fails, an appropriate message may be displayed to theuser, ref. 49, and the edit account settings screen is displayed, ref.45.

In an exemplary embodiment, a user who has tags already registered inthe system may edit the data, ref. 14, associated with them. Beforeentering this part of the program, subroutine D is executed in a mannersimilar to that previously described herein. Following verification ofthe “owner logged on” flag by subroutine D, the database is queried forall tags associated with a userid of the user, ref. 51. With referenceto FIGS. 1I and 9, for each such tag in the database, an informationline may be created, ref. 52, containing the tag's associatedinformation such as the tag ID 930, the date it was registered,description 940 and so on. Also, two links may be created for each tag,the links respectively allowing a user to “edit” the informationassociated with the tag, or “delete” the associated tag record from thedatabase. The list is then displayed 900 to the user, ref. 53. There mayalso be included on this menu, ref. 60, and its submenus, e.g., ref. 61,an option for the user to select to return to the main owner menu, ref.7, without entering any information. Should a user select a delete taglink 920, ref. 54, the tag record's description and owner userid areboth cleared in the database, ref. 55, making the ID available for lateruse. From this point, the list is refreshed beginning at ref. 51. If auser opts to edit a tag 910, ref. 57, then an editable field may bedisplayed, ref. 58, containing that tag's current description andoperable to allow the user to edit the description in a manner similarto that depicted in FIG. 5. Once the user chooses to save the newdescription, ref. 56, the database entry for that tag is updated, ref.59. From this point, the list is refreshed beginning at ref. 51.

Thus far, discussion has been made of how an owner of a tagged objectcan access and utilize a system in accordance with the present inventionin order to supply and/or manage at least contact information and tagIDs. Another aspect of the invention involves finders. A finder issomeone who has found an object, most likely lost, with an attached tagsuch as the exemplary tags depicted in FIGS. 2A and 2B. Such tags directa finder to, for example, a website or other virtual locale.

In a preferred embodiment of the present invention, a tag attached to anobject will direct a finder to access a website named thereon 220. Atsuch a website, the finder may select the finder option, ref. 5,resulting in the display of the finder main menu, ref. 66. The findermain menu provides selections related to finders. Additionally, thefinder may opt to return to the main menu, ref. 67.

According to one embodiment of the invention, a finder who is new to thesystem can select the option “new user,” ref. 70. The program thencreates and displays editable fields which may include fields for theuser's name and various types of contact information, ref. 100 (FIG.10). Required information may include a password and an unambiguouscontact information such as an email address. If a user selects to “addthe new user,” ref. 101, the system makes sure that the suppliedinformation is valid, ref. 102, and then adds the new user data to thedatabase, ref. 103. At this point, the main finder window is displayed,ref. 66 (FIG. 1J). Should the email address already exist in thedatabase, the user is alerted to the error, ref. 104, and the display isrefreshed, starting at ref. 100. Additionally, there may be an option,ref. 105, for the user to select to return to the main owner menu, ref.66, without entering any information.

Should a user select “Finder Log On,” ref. 68, they are prompted forcredentials such as their email address and a password, ref. 73 (FIG.1M). The database is then queried for a match to the enteredcredentials, ref. 74. If a match is found, then a flag is set toindicate that the finder is logged on for this session, ref. 75, and thefinder's unique user id, herein userid, is placed in memory for futurereference. If no match is found, an error message is displayed to letthe user know that they are not logged on, ref. 76. In either case, themain finder menu 1000 (FIG. 10) is displayed, ref. 66.

With reference to FIG. 10, in accordance with an exemplary embodiment ofthe present invention, when a finder wishes to see open cases, where anopen case is defined as an instance of an open line of communicationbetween a finder and an owner with regard to an owner's tag, the finderselects “view open cases” 1010, ref. 69. Before displaying open cases,however, subroutine L, as shown in FIG. 1L, is called. This subroutinechecks that the finder logged on flag is set to true, ref. 42, andreturns control to the application at the point of call to thissubroutine, ref. 43. If it is not, a suitable message is displayed tothe user, ref. 44, and the main finder menu is displayed, ref. 66. Ifsubroutine L verified the finder logged on flag, then the database isqueried for open cases, where a finder's userid is listed as the finder,ref. 77 (FIG. 1N). The retrieved data is used to create a list, ref. 78,which is displayed to the user, ref. 79. The list may contain one linefor each open case associated with the userid. A line may include twolinks which, respectively, enable the user to close the case, orcommunicate with the owner of that case. There may be numerous optionsthroughout this menu, and its submenus, including options, refs. 86 and87, to return to the main finder menu, ref. 66, without entering anyinformation. The user can close the case, ref. 80, which marks it asclosed in the database, ref. 81, and then refreshes the list, startingat ref. 77. Should the user select to contact the owner of a particularcase, ref. 82, a display is created with a data entry field in which theuser may enter an email message for the associated owner, ref. 83. In apreferred embodiment, the display includes an anonymous email address,created in accordance with the invention, which corresponds to theowner's actual email address. The display also includes a reminder tothe finder that they may optionally use the anonymous email address tocontact the owner using the finder's own email software. Once the userselects “send message,” ref. 84, the message is sent to the owner's realemail address, ref. 85. That email address is never displayed to thefinder. The display is then refreshed with the open case list bybeginning again at ref. 77.

Existing users can chose to edit their account settings 1020, ref. 72.Before displaying the edit account settings screen, subroutine L (FIG.1L) is called to validate that the finder logged on flag is set to truein a manner similar to that already described with regard to subroutineL. If the logged on flag is properly validated by subroutine L, the thedatabase is queried using the previously stored userid for informationassociated with this user's account settings such as name, addresses,password, email address, and so on. This information is displayed to theuser in editable fields, allowing the user to make changes, ref. 115(FIG. 1Q). Preferably, there is an option that the user may select, ref.120, to return to the main finder menu, ref. 66, without entering orsaving any information. Once the user selects save changes, ref. 116,the system confirms that the data are valid, ref. 117, and if so, savesthe changes to the database, ref 118, and displays the main finderwindow, ref. 66. If invalid data were found, appropriate error messagesare displayed to the user, ref. 119, and the display is refreshed fromref. 115.

In one embodiment a user may choose to search for an ID number, ref. 71.With reference to FIG. 11, upon such a selection, a display 1100containing a blank field 1110 will prompt the user to enter a search IDnumber, ref. 106. Preferably, there are options on this menu (not shownin FIG. 11), ref. 114, and its submenus, ref. 113, allowing a user toselect to return to the main finder menu, ref. 66, without entering anyinformation. Should the user enter an ID and click find, ref. 107, thedatabase is queried to see if the ID is valid and in use, ref. 108. Inone embodiment of the invention, entry to this part of the program, ref.108, may also occur from the main menu, where an ID field may exist forfast access to the search function. Should the ID not be a valid numberfor any reason, then the user is alerted, ref. 109, and the finder menu,ref. 66, is displayed. If the ID is valid, the description associatedwith it is shown, ref. 110, to the user. In a preferred embodiment, twonew choices may be displayed, allowing the finder to send a quickone-way anonymous message to the owner or to open up a new case andcommunicate using anonymous emails addresses.

With reference to FIG. 12, if the finder chooses to send a quick one-waymessage, ref. 111, the user is then prompted to enter an email messageinto a provided field 1210, ref. 129. Optional text on the display mayadvise the finder that the quick one-way message is indeed one-way andthat the owner will not be able to reply to the finder/sender.Preferably, there is an option, ref. 134, to return to the main findermenu, ref. 66, without entering any information. Once the user selects“send message,” ref. 130, the message is directed to the real emailaddress of the owner associated with the entered ID, ref. 131. Theowner's real email address is used but never displayed to the finder. Ifthe owner has any other contact information entered, ref. 132, forexample, Instant Message handles, then the message is also sent out viathose systems, ref. 133. The program then returns to the finder menu,ref. 66.

In one embodiment, a finder may choose to open a new case, ref. 112, fora tag ID associated with a found object. Prior to displaying a new casescreen, subroutine L (FIG. 1L) is executed to validate the user loggedon flag in a manner previously described for subroutine L. A newdatabase record is created for this case, ref. 121, and two anonymousemail addresses are generated. In an exemplary embodiment, one emailaddress begins with “Owner-,” ref. 122, and the other with “Finder-,”ref. 123. The generated email addresses may include a domain associatedwith the virtual locale. As an example, if the case involves ID277899028 and the virtual locale is associated with www.zReturn.com,then the generated addresses could be Owner-277899028@zReturn.com andFinder-277899028@zReturn.com. The real email addresses for both thefinder and the owner may be stored in the case record, ref. 124. Thefinder is then provided a data entry field and prompted to type amessage to the owner, ref. 125. Optionally, the owner's anonymous emailaddress may be displayed to the finder with a reminder that the findermay email the owner using the finder's own email program. Once the userselects “send email,” ref. 126, the message in the data entry field isdirected to the owner's real email address, ref. 127, and; the realemail address is never displayed to the user. The program can thenreturn to the finder menu, ref. 66. Preferably, there is an option, ref.128, on the new case screen allowing a user to return to the main findermenu, ref. 66, without entering any information.

With reference to FIG. 1Z, in a preferred embodiment, a serverperiodically executes a program to check for incoming email, ref. 88,being delivered to a domain associated with the virtual locale. If thereare no emails, the program halts, ref. 89 a. If an email has arrived,its “To” email address is checked for “Owner-,” ref. 90, “Finder-,” ref.91, and “Alert-,” ref. 91 a, to determine whether the email is addressedwith an anonymized email address. If not, then the email is forwarded toany other account setup for internal use on the server, ref. 92, and theprogram continues checking for new emails, ref. 88. If the “To” emailaddress begins with “Alert-”, then the email is passed off to the serverapplication that handles the Multi-protocol Messaging Translator, ref.165 (FIG. 1X). Otherwise, a case number associated with the “To” emailaddress is determined and the database is queried for a record of anassociated open case, ref. 93. If no such record exists, ref. 94, thenan auto-generated reply is sent to the sending email address, ref. 98,explaining that no such record exists, and the program starts checkingfor new emails, ref. 88, again. If a record does exist, the “From” emailaddress is checked versus the email address contained in the record,ref. 95. If the “From” email address is not the same as the record, thena reply is sent to the sender explaining that anonymous emails must besent from the same email address registered in the case record, ref. 99,and the program starts checking for new emails, ref. 88, again. Withreference to examples in FIGS. 13A and 13B, once email addresses havebeen confirmed, then the “To” anonymous email address 1320 is swappedwith a real email address 1340 as per the record and the real “From”email address 1310 is replaced with an anonymous address 1330 from therecord, ref. 96. Then, the email is forwarded to the new “To” emailaddress, ref. 97. The receiving user's id record is checked forassociated alert contact information such as AOL Instant Messenger,Yahoo Messenger, and/or Microsoft Messenger Handles and/or a cell phonetext messaging address. For any of those that the user provided, theemail is also forwarded to those systems, refs. 166, 167, 168, 169, 170,171, 172, 173, and 174 (FIG. 1Y). Then the program starts checking fornew emails, ref. 88, again.

With reference to FIG. 1X, in one embodiment, a program run by a serverchecks periodically for incoming messages from multiple messagingprotocols such as AOL, Yahoo, and MSN Text Messaging, ref. 135. If thereare no incoming messages, ref. 136, the program halts, ref. 137. Ifthere is a message, the first word of the message is isolated, ref. 138,and checked against the database to see if it is a valid ID. If it isnot a valid ID, or there is only one word in the message, then a simpleinstruction message, such as “How to properly use the system” is sentback as a reply to the sender, ref. 139, and the program goes to checkfor other new messages.

If the ID is valid, the messaging screenname that sent this message ischecked, ref. 140, against all forms of messaging names and protocolsassociated with the owner who registered the ID number contained in themessage. If it is determined that this message came from the owner ofthe ID to which the message refers, then control is passed over to ref.161. If none of the owner associated names and protocols match thesender of the message, then a messaging database is queried to match upthe ID and the message's screenname and protocol, ref 141. If no recordis found, then a record is created, linking the ID, the screenname, andthe protocol, refs. 142, 143, and 144.

Continuing with the exemplary embodiment for handling inbound InstantMessages, the inbound message will be directed to the owner's designatedIM addresses. With reference to FIG. 14, for each existing form of alertthat the owner registered, e.g. AOL, MSN, Yahoo, cell phone textmessaging, and so on, the software will make a new message that mayoptionally include an introduction concerning the nature of the message1410 and how to properly reply to it. The message will include themessage sent by the sender 1420. The message will be sent to each ofthese messaging options registered by the owner, refs. 145, 146, 147,148, 149, 150, 151, 152, 153, 154, 155, 156, 157, and 158 (FIG. 1U). Anew message, as described above, may optionally be sent to the owner'semail address. The “From” email address may be of a form similar to“Alert-XXX@zReturn.com,” where XXX is the ID number. The softwareapplication then looks for more incoming messages, ref. 135 (FIG. 1X).

Finally, if it is determined that the inbound message originated from anowner of an ID to which the inbound message refers, then the applicationlooks in the alert database for the record created by the sender of theoriginal message, refs. 141, 142, 143, and 144. If no record can befound the application halts, refs. 161, 161 a. Otherwise, the screennameand protocol are pulled from the found record, and a new message iscreated which may optionally include an introduction on what thismessage is, and how to properly reply to it. The message includes themessage sent by the sender. The new message is then sent to thescreenname and platform from the record in the alert database, refs. 161b, 162, 163, and the program continues to look for more messages, ref.135.

The foregoing disclosure of the preferred embodiments of the presentinvention has been presented for purposes of illustration anddescription. It is not intended to be exhaustive or to limit theinvention to the precise forms disclosed. Many variations andmodifications of the embodiments described herein will be obvious to oneof ordinary skill in the art given the above disclosure. The scope ofthe invention is to be defined only by the claims appended hereto, andby their equivalents.

Further, in describing representative embodiments of the presentinvention, the specification may have presented the method and/orprocess of the present invention as a particular sequence of steps.However, to the extent that the method or process does not rely on theparticular order of steps set forth herein, the method or process shouldnot be limited to the particular sequence of steps described. As one ofordinary skill in the art would appreciate, other sequences of steps maybe possible. Therefore, the particular order of the steps set forth inthe specification should not be construed as limitations on the claims.In addition, the claims directed to the method and/or process of thepresent invention should not be limited to the performance of theirsteps in the order written, and one skilled in the art can readilyappreciate that the sequences may be varied and still remain within thespirit and scope of the present invention.

Furthermore, a person skilled in the art will recognize that someaspects of the present invention, described with reference to a sequenceof condition checks, may be easily implemented with an event driven codedesign.

Aspects of the described system and method may be implemented in aprogramming language such as the Perl programming language inconjunction with the Apache open source web server software and theMySQL open source relational database running under the Linux operatingsystem. Additionally, those of skill in the art are aware of open sourcemodules available to aid in implementing aspects of the presentinvention. For example, the Perl module Net-Oscar is available fromcpan.org and is operable to interface with instant messaging systemssuch as AOL instant messenger and ICQ. However, other programminglanguages, operating systems, and database systems are adaptable to thepresent invention and may also be used.

We claim:
 1. A method of facilitating communication between a finder ofan article and an owner of the article comprising: providing a unique IDto the owner; allowing the owner to register an association between theID and a contact information of the owner; allowing the owner toassociate the ID and a virtual locale with the article; forwarding acommunication of the finder of the article to the owner wherein thefinder has provided the ID and the communication to the virtual locale.2. The method of claim 1 further comprising: allowing the finder toprovide a contact information of the finder; and forwarding an ownercommunication to the finder wherein the owner has provided said ownercommunication and unique ID to the virtual locale.
 3. The method ofclaim 1 wherein the contact information is one or more of an emailaddress, an instant messaging handle, and a cell phone number.
 4. Themethod of claim 1 further comprising: generating a unique anonymousemail address for each of one or both of the finder and the owner, saidemail address including a domain associated with the virtual locale; andanonymizing and forwarding email delivered to said email address to acontact information of the addressee.
 5. The method of claim 1 furthercomprising: allowing the owner to register a plurality of contactinformation wherein each contact information may be one of an emailaddress, an instant messaging handle, and a cell phone number, whereinforwarding the communication further comprises forwarding thecommunication to each of the plurality of contact information.
 6. Acomputer implemented system for facilitating communication between afinder of an article and an owner of the article comprising: a virtuallocale; a database for storing an association between a contactinformation of the owner and a unique ID; and a module for forwarding acommunication of the finder of the article to the owner of the articlewherein the finder provides the communication and the unique ID to thevirtual locale.
 7. The system of claim 6 further comprising: a modulefor generating a unique anonymous email address for each of one or bothof the finder and the owner, said email address including a domainassociated with the virtual locale; and a module for anonymizing andforwarding email delivered to said email address to a contactinformation of the addressee.
 8. The system of claim 6 furthercomprising a module for forwarding the communication to an instantmessaging system if the contact information comprises an instantmessaging handle.
 9. The system of claim 6 wherein the database isoperable to store a plurality of contact information of the owner,wherein each contact information may be one of an email address, aninstant messaging handle, and a cell phone number; further wherein themodule for forwarding the communication is operable to forward thecommunication to each of the plurality of contact information of theowner.